Hmmmm, here's the new error that suddenly popped up

Error: [$parse:lexerr] Lexer Error: Unexpected next character  at columns 0-0 [\] in expression [\"OauthButtons.loginOauth("facebook")\"].
    http://errors.angularjs.org/1.5.7/$parse/lexerr?p0=Unexpected%20next%20character%20&p1=s%200-0%20%5B%5C%5D&p2=%5C%22OauthButtons.loginOauth(%22facebook%22)%5C%22 (line 22117)

IDK why this suddenly popped up

Planning on merging in one commit with fixes for most of the TypeScript type errors tomorrow (monday), just missing a few for some tests and one jquery + protractor typing that cannot be mixed. Think we essentially need to separate the regular typings from the test typings to fix the latter error. Just need to observe that the changes for babel look okay as well.

Biggest changes are probably interfaces for the admin and user services.An annoying addition is however that you have to tell typescript which type is being returned for the functions that are either asynchronous or synchronous as it cannot tell them apart from how many parameters you send in, nor do they apparently plan on supporting that in the future. Could alternatively also refactor the methods to be named differently depending on if they're asynchronous or synchronous. Would then organically work as expected.

@Awk34 Do you figure that there's much more left to get the build to work other than fixing a few things in the gulp pipeline that starts webpack? Also a bit confused about what actually starts webpack when running gulp serve. From the log I'm thinking it's in start:client or start:server but can't find the starting point. Something similar planned for gulp build or using the webpack:dist task?

Either way, thinking of trying to get some basic build up and running tomorrow, any pointers or instructions would thus be highly welcomed.

Yeah, I definitely want to split those into two methods (fn & fnSync). You should never have the same function able to be sync or async. The sync part is only used in Angular templates, which is also kind of an anti-pattern in and of itself, but for now that can stay as-is.

I think we're close to being able to merge it into canary.

When in development, webpack is actually being run from inside the express server, here. This is to achieve the right pairing of the full-stack nature with live-reload.

What specific are you looking for in terms of pointers/instructions?

Yeah, I definitely want to split those into two methods (fn & fnSync). You should never have the same function able to be sync or async. The sync part is only used in Angular templates, which is also kind of an anti-pattern in and of itself, but for now that can stay as-is.

Sounds good.

When in development, webpack is actually being run from inside the express server, here. This is to achieve the right pairing of the full-stack nature with live-reload.

Ok, finally makes sense to me then :). Should be fine to remove gulp task webpack:dev then, right?

Slightly related to that, do you have any strong feelings or insights concerning browser-sync vs live-reload? I.e. #1955, as stated there I think there are some more compelling features with browser-sync, I am not confident that it's strictly better or that browser-sync itself does not lack some features that live-reload has. Either way I would consider just getting webpack and likely most of Angular 2 working higher priority.

What specific are you looking for in terms of pointers/instructions?

Think I'm mostly looking for a small summary on what's left to make the build work, including any thoughts you have on the overall flow. So that I don't unnecessarily go down a completely different road.

Right now I'm thinking it's only about removing deprecated gulp tasks in the gulp build pipeline and then possibly doing some adjustments to the webpack build configuration. Just a bit unsure of how much webpack is doing and how much, if anything is left to get a reasonable webpack build going.

Should be fine to remove gulp task webpack:dev then, right?

We could leave it. It's not doing any harm. IDC.

I have no real opinion on browser-sync vs live-reload.

Think I'm mostly looking for a small summary on what's left to make the build work, including any thoughts you have on the overall flow. So that I don't unnecessarily go down a completely different road.

I think the flow is pretty good right now. Removing any more code that we don't need anymore is fine by me. I'm going to be mainly doing cleanup now.

One thing is we still need to figure out why the E2E tests have started failing. They run fine locally still, but not on CI. I don't get it.

Right now I'm thinking it's only about removing deprecated gulp tasks in the gulp build pipeline and then possibly doing some adjustments to the webpack build configuration. Just a bit unsure of how much webpack is doing and how much, if anything is left to get a reasonable webpack build going.

If you're unsure, don't commit directly to this branch. You might also wait until this is merged into canary, and then make another PR. I plan on merging this branch into canary this week.

@Koslun one thing to mention: I'd like to keep as many of the type annotations language-agnostic as I can (TypeScript / Flow). The way the main generator works right now, is the files are run through EJS, and then Babel. I have it default to always use the 'babel-plugin-transform-flow-strip-types' plugin, which removes all type annotations, just because I was lazy and haven't confirmed that Flow works out-of-the-box with our setup (I should do that soon). But the takeaway is, if you can, make type annotations work with both TS & Flow. (Use the filters.flow value alongside filters.ts)

So that also means that if there's a typing that would work for both TS & Flow, there's no need to add EJS around it, since Babel would be able to interpret it.

One thing that just occurred to me: I have all the front-end dependencies in the dependencies section of package.json, but they can go into the devDependencies section, since they're not needed in prod since Webpack would package all that up at build-time.

We could leave it. It's not doing any harm. IDC.

Yeah the only harm it can do is be slightly confusing to anyone who peeks at it, so just leaving it for now then.

I have no real opinion on browser-sync vs live-reload.

Probably going to explore that once Angular 2 and its extra features are in browser-sync.

But the takeaway is, if you can, make type annotations work with both TS & Flow

Yeah I scoped all of the types to filters.ts as I have also been lazy to really setup a Flow environment and thus confirm what works as expected in Flow. Am particularly unsure about how well typings work with Flow. Once it's up, I can have a look at scoping the types more precisely to TS, Flow or both.

If you're unsure, don't commit directly to this branch. You might also wait until this is merged into canary, and then make another PR. I plan on merging this branch into canary this week.

Sounds good. Will experiment a little locally and either get a new PR up once this is merged or try to contribute if you setup another PR for it.

One thing that just occurred to me: I have all the front-end dependencies in the dependencies section of package.json, but they can go into the devDependencies section, since they're not needed in prod since Webpack would package all that up at build-time.

Yeah, that is interesting. I do however wonder how exactly this is solved with Angular Universal. Have to get Angular 2 up first though.

@Koslun I've backed out that latest commit for now (I put it on the ts-stuff branch for safe keeping)